A. Field of the Invention
This invention relates to a method for compressing identifiers of program code elements in a portable data carrier, to a method for calling compressed identifiers, to a portable data carrier, and to a semiconductor chip having a memory area for storing the compressed identifiers.
B. Related Art
Chip cards having a microprocessor, also designated smart cards, are already used today, and will probably be used increasingly in the future, in a multiplicity of applications, for example in mobile devices such as e.g. mobile telephones as SIM cards or USIM cards, as bank cards or electronic purses in electronic payments, as health cards for persons having health insurance and for doctors, as citizen cards, or as multi-application cards in which several of the stated or other functionalities are implemented.
A semiconductor chip for the chip card has a plurality of memory areas, namely, the non-volatile, only once-writable ROM, the non-volatile, rewritable EEPROM and the volatile, rewritable RAM. Alternatively, parts of the ROM and/or of the EEPROM can be replaced by flash memories. In FIG. 1 these relations are represented. A chip card 2 is in a communication connection 3 with an end device 1 here.
Upon the manufacture of the semiconductor chip a program code portion is first implemented in the ROM by the chip manufacturer. This program code portion is also designated a ROM mask and contains primarily the operating system of the chip card. The chip-card manufacturer obtains the ROM mask from the chip manufacturer. The completion of the chip card is normally likewise carried out by the chip-card manufacturer, for which purpose additions to the operating system and applications of the chip-card manufacturer are implemented into the EEPROM of the chip card. After successful completion the semiconductor chip is ready to be delivered to the customer.
To create applications that are platform-independent and well protected from each other, it is very suitable to use object-oriented programming languages, in particular Java™ from the company Sun Microsystems Inc. Alternatively to Java™ a suitable programming language is also C#. However, the runtime environments of object-oriented programming languages are normally too extensive to be able to be readily implemented into a smart-card chip.
The Java Card™ technology of the company Sun Microsystems Inc. represents a modified Java technology for runtime environments with limited system resources, which is also suited for chip cards. This technology is set forth for example in the document “Java Card™ Runtime Environment (JCRE) Specification” in version 3. It is noted that the invention is not limited to the current or past versions of the specification, but rather is also valid for future versions. A schematic structure of the Java Card™ technology is shown in FIG. 2, which will be described more closely in the description of the figures. The runtime environment according to the JCRE specification, which is provided in the semiconductor chip of a Java Card, comprises at least the Java Card Virtual Machine (JCVM) and identifiers stored in a corresponding memory area, as well as optionally further components.
In connection with the invention, an identifier is an identifying means with which elements, for example a variable, a class, a method, a parameter list, a function or a package of a program code are labeled. To avoid collisions upon calling of this object, an identifier must be unique within a name space, i.e. it must be collision-resistant. Object-oriented programming languages distinguish between simple and fully qualified identifiers. A compiler always translates simple identifiers, which normally serve as programming aids, into fully qualified identifiers. A fully qualified identifier is constructed hierarchically, whereby individual parts are separated by a period. In Java there is a naming pattern for identifiers. Parts of the identifiers that are arranged lower down in the naming hierarchy have no relationship semantically to the parts of the identifiers that are higher up in the hierarchy.
In the chip card the identifiers are stored according to the specification as a character string, also called string, of characters of the data type character (char).
The memory area for the operating system of a chip card is normally very small, only a small part of which is available to a user. Hence, chip-card manufacturers always endeavor to increase the part of the memory area available to the user. To be able to make as much memory area as possible in the EEPROM or in the flash memory available to the user, the operating system of the chip card must hence be configured such that as little memory as possible is occupied.
Applications are normally implemented in the chip card in the form of applets. As applications there are so-called preloaded applets, which are implemented into the chip-card chip before or upon completion. Further, there are postloaded applets, which are loaded into the chip-card chip after successful completion, normally by the buyer or customer, for example a credit institution or a government agency. This is where the great advantage of the Java Card™ technology is to be seen, because the applets can be transferred to the chip card independently of platform, so that the hardware present on the respective chip card no longer plays a role upon implementation and execution of the applet. While in the Java Card 2.x applets are loaded, in the Java Card 3.0 so-called servlets and web services are additionally loaded. In connection with the invention no distinction is made between applets, servlets and web services, there is generally spoken of applications.
The invention is not limited to one version, for example the current version Java Card 3.0, of the standard, but rather the proposed compression method can also be applied to older and future Java standards. In the version of the Java Card standard 2.x the Java program code of an application is stored in the chip card in the form of Java packages. A Java package in turn consists of several class definitions. Additionally, interfaces can also be defined in the Java package. The Java program code is divided here over several translation units, each of which is stored in its own file. Each individual translation unit first defines the package to which it belongs and then imports one or several classes from other Java packages. Additionally, interfaces from other Java packages can also be imported. Finally, one or several classes and possibly additionally interfaces are defined in the Java package. One Java package draws on another Java package, so to speak. This measure prevents packages, classes and/or methods from existing on a chip card in multiple fashion, so that memory space on the chip card is already saved at this point.
That a package newly loaded into a Java Card can actually access a predetermined other package and use its program code is established by linking. The newly loaded package loads link information (e.g. an address) from an export component of the other package into its own import component. For example, a token, i.e. a number reference generated from an “import” reference, in the import component of the new package is replaced, upon linking, by an address from the export component of the other package. This causes the token (the reference) with the desire for use to be replaced by an actual address link between the two packages. The link and thus the actual possibility of use can only be established when the newly loaded package has available thereto the export component of the other package whose program code wants to use the new package.
The export components of all packages that are implemented in a Java Card, or a predetermined subset of all these export components, are combined in the export file. If an additional (new) package is transferred to the chip card before completion of the Java Card, it is linked employing the linker and the export file.
The structuring of the program code into packages is still retained after the transfer to the portable data carrier.
As mentioned at the outset, in the Java Card technology, identifiers for executable program code elements are stored in the chip card, whereby the identifier in turn states the package and the class name in which the executable program code is stored. The identifiers are stored here as so-called strings, in the character data type (char). Each char character of the string requires 8 bits in the memory area of the chip card. Hence, one starting point for saving memory space in the memory area of the chip card is attainable by effectively storing the identifiers on the chip card.
In JP 2000259425 A there is stated a method for compressing identifiers. The identifiers are first stored as strings of char and are analyzed with regard to redundant strings. Each string of a first identifier that is completely contained in a string of a second identifier is not stored separately. Instead, the first identifier is stored such that the first char character of the first identifier is marked on the string of the second identifier. The first identifier is discarded and only the marking and the length of the string of the first identifier is stored in the memory area of the chip card.
Such a compression initially means that at least one string of an identifier is completely stored. Each identifier of a Java package, of a class or of a method that has not previously been stored as a string of char at least once must be stored in the memory area of the chip card in the conventional way. Therefore, this compression method is not effective, since a lot of space is employed for the identifiers.